When an organization node contains lots of
folders, projects, and resources, a workforce might need to restrict who has access to what. To help with this task, administrators can
use Identity and Access Management, or IAM. With IAM, administrators can apply policies
that define who can do what and on which resources. The “who” part of an IAM policy can be a Google account, a Google group, a service account, or a Cloud Identity domain. A “who” is also called a “principal.” Each principal has its own identifier, usually
an email address. The “can do what” part of an IAM policy
is defined by a role. An IAM role is a collection of permissions. When you grant a role to a principal, you
grant all the permissions that the role contains. For example, to manage virtual machine instances
in a project, you must be able to create, delete, start, stop and change virtual machines. So these permissions are grouped into a role to make them easier to
understand and easier to manage. When a principal is given a role on a specific element of the
resource hierarchy, the resulting policy applies to both the chosen element and all
the elements below it in the hierarchy. You can define deny rules that prevent certain
principals from using certain permissions, regardless of the roles they're granted. This is because IAM always checks relevant
deny policies before checking relevant allow policies. Deny policies, like allow policies, are inherited
through the resource hierarchy. There are three kinds of roles in IAM: basic,
predefined, and custom. The first role type is basic. Basic roles are quite broad in scope. When applied to a Google Cloud project, they
affect all resources in that project. Basic roles include owner, editor, viewer,
and billing administrator. Let’s look at these basic roles in a bit
more detail. Project viewers can access resources but can’t
make changes. Project editors can access and make changes
to a resource. And project owners can also access and make
changes to a resource. In addition, project owners can manage the
associated roles and permissions and set up billing. Often companies want someone to control the
billing for a project but not be able to change the resources in the project. This is possible through a billing administrator
role. A word of caution: If several people are working
together on a project that contains sensitive data, basic roles are probably too broad. Fortunately, IAM provides other ways to assign
permissions that are more specifically tailored to meet the needs of typical job roles. This brings us to the second type of role,
predefined roles. Specific Google Cloud services offer sets
of predefined roles, and they even define where those roles can be applied. Let’s look at Compute Engine, for example,
a Google Cloud product that offers virtual machines as a service. With Compute Engine, you can apply specific
predefined roles—such as “instanceAdmin”—to Compute Engine resources in a given project, a given folder, or an entire
organization. This then allows whoever has these roles to perform a specific set of predefined actions. But what if you need to assign a role that
has even more specific permissions? That’s when you’d use a custom role. Many companies use a “least-privilege”
model in which each person in your organization is given the minimal amount of privilege needed
to do their job. So, for example, maybe you want to define
an “instanceOperator” role to allow some users to stop and start Compute Engine
virtual machines, but not reconfigure them. Custom roles will allow you to define those
exact permissions. Before you start creating custom roles, please
note two important details. First, you’ll need to manage the permissions
that define the custom role you’ve created. Because of this, some organizations decide
they’d rather use the predefined roles. And second, custom roles can only be applied
to either the project level or organization level. They can’t be applied to the folder level.